As is generally understood in computing environments, an operating system (O/S) acts as the layer between the hardware and the software providing several important functions. For example, the functionality of an O/S includes device management, process management, communication between processes, memory management, and file systems. Further, certain utilities are standard for operating systems that allow common tasks to be performed, such as file access and organization operations and process initiation and termination.
Within the O/S, the kernel is responsible for all other operations and acts to control the operations following the initialization functions performed by the O/S upon boot-up. The traditional structure of a kernel is a layered system. Some operating systems use a micro-kernel to minimize a size of the kernel while maintaining a layered system, such as the Windows NT operating system. FIG. 1 illustrates an example diagram of a typical layered structure, such as for the Windows NT operating system. As shown, the applications 10 lie above the O/S 20, where each application typically resides in its own memory space. The micro-kernel 30 interacts with a hardware abstraction layer 40 (e.g., with device drivers) associated with hardware layer 50. The line 60 represents a demarcation line indicating the separation between which normally is considered the user space of the applications, and the protected space of the operating system.
While the typical structure provides a well-understood model for an operating system, some problems remain. One such problem is the potential for crashing the machine once access below the demarcation line 60 is achieved. For example, bugs in programs that are written for performing processes below the demarcation line, e.g., device drivers that interact with the hardware abstraction layer, protocol stacks between the kernel and the applications, etc., can bring the entire machine down. While some protection is provided in operating systems with the generation of exceptions in response to certain illegal actions, such as memory address violations or illegal instructions, which trigger the kernel and kill the application raising the exception, there exists an inability by operating systems to protect against the vulnerability to fatal access.
An approach to avoiding such vulnerability is to limit which software is trusted within an operating system and utilizing control mechanisms that check all other programming prior to processing. Relying on software to perform such checks reduces the ability to limit the amount of software that is trusted. A hardware solution would be preferable, but, heretofore, has been prohibitive due to the level of instantaneous hardware machine generation that would be necessary.
Accordingly, what is needed is an ability to achieve a protected operating system through on demand hardware monitoring. The present invention addresses such a need.